I. Technical Field
The present invention pertains to telecommunications, and particularly to the mitigation of jitter in traffic communicated between network nodes.
II. Related Art and Other Considerations
In many types of communications network, traffic (typically in the form of a stream or flow of data packets) is transmitted over a channel or link between a network sending node and another network (receiving) node or a terminal. The transmission of such packets is generally performed in conjunction with provision of some type of service utilized by client (e.g., a client application which is executed at terminal of the network, for example). Some of these services (such as streaming media, for example) are very sensitive to delay, meaning that quality of the service is very dependent upon timely delivery of the packets to the client.
A packet is often stored or buffered by the sending node in a queue or “buffer” of the sending node until such time as it is deemed appropriate for the packet to be “scheduled” out of the sending node for transmission (over the channel, link, or interface) to a receiving node or terminal. The sending node often employs a scheduler or scheduling algorithm for determining when a packet is to be transmitted to the receiving node or terminal.
Conventional schedulers and/or scheduling algorithms for delay sensitive services typically make scheduling decisions (for determining when to transmit a packet out of a scheduling buffer of a node for transmission, e.g., to another node) on the basis of a length or time (e.g., delay) that the packet has experienced, e.g., in the buffer. Such scheduling algorithms are described by, e.g., Hosein, P. A, “Qos Control For WCDMA High Speed Packet Data”, 4th International Workshop on Mobile and Wireless Communications Network, 2002, pages 169-173, 2002, incorporated herein by reference. Thus, delay is usually measured as the time each packet has spent in the scheduling buffer. Given a certain maximum delay requirement of a flow, the scheduling algorithm is designed so that priority is increased as the delay threshold is approached. The basic approach of the conventional scheduling algorithms is to guarantee delivery before a deadline, but also to allow non-delay sensitive traffic to be scheduled (e.g., non-delay sensitive packets to be read out of the buffer) if time allows.
Consider, for example, a connection in which a radio base station (also called in a “NodeB” in some RAN contexts) is receiving traffic in the form of packets from a backbone network or another node in a radio access network (RAN), in the manner generally depicted in FIG. 1. The wireless terminal 130 receives the packets for, e.g., use in a client application program executed at the wireless terminal. The client application may be, for example, a streaming player (such as Realplayer, for example). The traffic may have been received over cascaded radio links (e.g., originated by a sending wireless terminal 182 and over a radio interface and through the radio access network) or received in a transmission chain which similarly imposes jitter. “Jitter” is the variation in the time between packets arriving, caused by network congestion, timing drift, or route changes.
For example, the packets received by the radio base station 122 of FIG. 1 are obtained from a transmission chain comprising a backbone network, another radio base station 180, and a sending wireless terminal 182. In-order delivery and scheduling on the uplink from sending wireless terminal 182 toward, e.g., the backbone network, will cause jitter and resulting bursts of packets. In FIG. 1, data flows from left to right, and packets stacked on one another depict packet bursts (broken lines point to positions the packets would occupy if the burst had not occurred). Each burst is seen by every node in the transmission chain after the point were the jitter occurred.
The radio base station 122 stores the packets in a scheduling buffer 138 until such as time as is deemed appropriate for transmitting the packets over the air interface to the wireless terminal 130 (e.g., the scheduler of node 122 determines a delay factor calculated based on the delay since the packets entered scheduling buffer 138). Of the packets arriving at the radio base station, the first such packets have experienced the most or greatest delay. Thus, packets entering the scheduling queue will have spent different amounts of time in the network. Basing the scheduling priority on the time spent in the scheduling buffer will cause or convey a jitter in the traffic entering the wireless terminal 130, such as that depicted in FIG. 2.
As the packets are received at the wireless terminal from the sending node, the packets are stored in a playout buffer 148 by the client application of the wireless terminal 130. The packets are read out from the playout buffer 148 by the client application in accordance with (e.g., at a time determined by) the client application.
The problem with such conventional scheduling algorithms is that, in a system with cascaded radio links (or any other sources for jitter in the transmission chain before the scheduler), the delay scheduler/scheduling algorithm is not aware of the remaining delay budget of each individual packet. That is, the delay scheduler/scheduling algorithm is not aware of how long the packet can stay in the scheduling buffer 138 of node 122 before the packet retention causes the playout buffer 148 in terminal 130 to be drained of packets or go dry. Drainage of the playout buffer, attributable to the jitter, is not at all desirable and should be avoided.
Conventionally the jitter in the traffic entering the wireless terminal is handled or mitigated in and by the wireless buffer. From a theoretical vantage point, in order to be able to most effectively handle jitter, the wireless terminal should be aware of the expected jitter on the incoming traffic. Though this is (at least in theory) possible, in practice it is difficult to share jitter-related information between the network and the client application of the wireless terminal which is receiving the packets. What typically happens therefore, in state of the art scheduling, is that the client application has to “prebuffer” a certain amount of data in the client's playout buffer before starting the playout. In so doing, the amount of data that is prebuffered should correspond to the expected amount of jitter in the transmission chain.
What is needed, and an object of the present invention, are one or more of apparatus, method, and technique for mitigating jitter in a telecommunications system.